Collaborative environments are becoming pervasive in the industry. One area of collaboration that is critical to an enterprise is that which is associated with new software development. During software development a variety of different developers can be working on the same or dependent modules at the same time and from entirely different processing environments from one another. A variety of different project life-cycle and version control systems attempt to coordinate project activities in scenarios such as this.
One problem that nearly every software development project faces is module dependency. That is, one developer may be working on a particular aspect of the project and may have a valid reason for renaming or even moving one of his/her software modules. However, other developers working on other aspects of the project may be entirely unaware of this and may have coded their modules to specifically reference the first developer's module in its old location. This creates module brittleness and results in a lot of project churn and inefficiency.
Stated another way, a significant drawback to project-based environments is that often individual developers have complete control over where they store their software and other project members often rely on that software. A developer may have a temporary fix that needs to be made to a module and may temporarily move it and then forget to put it back where it belongs. Alternatively, the developer may have created other dependencies with other software and may legitimately need to permanently change the location of the software. When the other dependent project members process their code, their code breaks because the location of the software to which they relied on changed. This situation is a common occurrence in software development and happens very frequently.
Thus, what is needed are improved techniques for resolving the locations of project modules in a project-based environment so as to reduce brittleness associated with the conventional approaches.